---
title: "Fingerprints"
sidebarTitle: "Fingerprints"
description: "Fingerprints are unique identifiers associated with alert instances in Keep. Every provider declares the fields fingerprints are calculated upon"
---

<Warning>
  Fingerprints defaults to Alert Name if the provider does not declare
  fingerprint fields.
</Warning>

Fingerprints serve several important purposes in the context of alerting within Keep:

### De-Duplication

Alert fingerprints are used to prevent the duplication of enrichments/workflows triggering for the same underlying alert.
When Keep receives an alert, it calculates a fingerprint based on the configured fields declared within the Provider.
If two alerts have the same fingerprint, Keep considers them to be duplicates and will present one of them.
This helps reduce alert noise and prevent unnecessary workflow triggers/enrichments.

### Grouping

Keep uses alert fingerprints to group related alerts together.
Alerts with the same fingerprint are considered to be part of the same group, indicating that they are triggered by the same underlying condition or problem.
Grouping alerts makes it easier for operators to understand relations between different alert-sources, the root cause of an issue and take appropriate action faster.

### Silencing

Alert fingerprints are used in third-party tools to manage silences/mutes.
Silencing allows operators to temporarily suppress alerts with specific fingerprints, providing a way to acknowledge and handle known issues without generating additional notifications/triggers.

### Visualization

Alert fingerprints can also be used for visualization and analysis purposes.
They help in tracking the history and status of alerts over time and provide a means to correlate alerts with specific conditions or changes in the monitored system.

The process of generating a fingerprint involves hashing the fields configured in the provider and their values associated an alert instance.
This results in a fixed-length, hexadecimal string that uniquely identifies that alert.
When Keep receives/gets an alert, it calculates the fingerprint for each alert to determine if it should trigger a workflow, be grouped, or is silenced.

In summary, Keep alert fingerprints are essential for managing and organizing alerts in every third-party system.
They help prevent duplicates, group related alerts, enable silencing, and facilitate analysis and visualization of alert data, ultimately aiding in the effective operation and maintenance of monitored systems.

### Examples

This is the base provider class implementation for fingerprint fields:

```python base_provider.py
class BaseProvider(metaclass=abc.ABCMeta):
    OAUTH2_URL = None
    PROVIDER_SCOPES: list[ProviderScope] = []
    PROVIDER_METHODS: list[ProviderMethod] = []
    FINGERPRINT_FIELDS: list[str] = []
```

This is Datadog's provider implementation for fingerprint fields, where we calculate fingerprint based on the event groups and monitor id, as an example:

```python datadog_provider.py
class DatadogProvider(BaseProvider):
    """
    Datadog provider class.
    """

    PROVIDER_SCOPES = [
      ...
    ]
    PROVIDER_METHODS = [
      ...
    ]
    FINGERPRINT_FIELDS = ["groups", "monitor_id"]
```

<Card title="Customization" icon="lightbulb" iconType="duotone" color="#ca8b04">
  Keep allows for customization in anything related with fingerprints. If you
  want to change the way a specific provider calculates the fingerprint of an
  alert, you can simply configure the fields you require.
</Card>
